Aminet 1 (Walnut Creek)/Aminet - June 1993 [Walnut Creek].iso/aminet/util/misc/softboot331.lha/softboot3.31/ReadMe.SoftBoot

Text File | 1992-11-09 | 26KB | 482 lines

                        SoftBoot Documentation

Last Updated 11/09/92 for SoftBoot 3.31

INTRODUCTION

Well, you've just bought that 68040 card for your A3000 or just thought
putting ROMs in your A3000 was a good idea. Commodore has begun to ship A3000s
with 2.04 (or later) Roms built-in. You've lost your SuperKickstart feature,
haven't you? This means that you can't run, in a recoverable fashon,  new Beta
versions of the A3000 AmigaDos Operating System or can't even run measley old
1.3. Until Now. Introducing 'SoftBoot', the new SuperKickstart Emulator for the
A3000. Supporting the 68040 and the built-in 68030 CPU of the A3000, you can
now run any version of the operating system (including 1.3!) in a completely
reboot-survivable way. Many hundreds of hours and many hundreds of power cycles
on my poor old A3000 have resulted in a near bullet-proof implementation. The
process of reboot recovery is clean and unobtrusive to the new OS. There is no
old OS aftertaste, so to speak. Cold|Cool|WarmCapture are not used. Program
failure will result only if the ROM image, ExecBase structure, MMU tables,
or reboot recovery routines are corrupted by an errant program.

What do you need to run SoftBoot? Besides this very powerful program, you
need SuperKickstart files. SoftBoot will load the devs:Kickstart file
for 2.04+ versions of AmigaDos (including 3.0), or it can load the
Devs:Kickstart1.3 file for AmigaDos 1.3. Note these must be the SuperKickstart
versions with attached 'bonus' areas. Some interesting variations will be
discussed later on.

You must use OldFileSystem or FastFileSystem for your system paritions. I
highly recommend creating a System2.0: partition and a System3.0: partition
and using HDToolBox to enable the one you wish to boot from. If you create a
unique filesystem partition, like MS_DOS or DCFileSystem partitions, PLEASE:
MAKE SURE THAT THE FILESYSTEM IS LOADED INTO THE RIGID DISK BLOCK (RDB)!!!!!

Failure to do so may render the data unreadable under 2.04 and who knows what
damage may occur. Softboot is not responsible for any damage if that occurs. In
general, this software is provided as-is and the user accepts all risks in
using it.

SoftBoot V3.31 and later

There are a number of powerful operations possible with SoftBoot. Some
which work on other machines besides the A3000. For example, the SOFTBOOT
parameter performs a soft reset of any Amiga. If you try to use a
feature of SoftBoot that your Amiga does not support, it will (usually)
tell you. If you invoke SoftBoot with the '?' parameter, you will get
the following text printed on your Shell:

SoftBoot V3.31 [NOCACHEZ2][KILLROM][NOCATCHROM][ONETHREE]
               [BOTH][SOFTBOOT][NOBUSERRORS][FASTROM]
               [ENTTX][OVRMMU][NOCACHEZ3][Z3ALL]

Each of the parameters will be discussed next:

FASTROM

The FASTROM parameter causes the current motherboard ROM to be copied into
fast RAM and remapped with the MMU. While you can do this with a 68030 and
the 'CPU' program, SoftBoot works with both 68030 and 68040 systems. It
will even accomodate non-A3000 68020/68851 systems! The FASTROM setup will
die on any hardware reset (Ctrl-LAmiga-RAmiga).

KILLROM

To kill any MMUed ROM setup and reboot the machine, use the KILLROM parameter.
Note that it takes effect with no time delay. Make sure all files are closed
and that there is time for the final write to occur before performing this
command. KILLROM wipes out RAD:, too.

SOFTBOOT

The SOFTBOOT Parameter will work with any Amiga. It simply performs a
system friendly reboot. It also takes effect immediately. The SOFTBOOT
parameter is to be used primarily for forcing a MMUed OS to load a floppy
disk-based game or program without going through the reboot recovery
procedure. This guarantees that you will get the purest OS that money
can buy! The same warning in KILLROM applies here: Make sure all files are
closed and there is time for the final write to occur before executing
the SOFTBOOT parameter.

This routine simply calls the ColdReboot() function. Avoid making 3.0 EPROMS
and running SoftBoot's FASTROM option. This option just temporarily allocates
the memory for the ROM and MMU tables. If the MMU is on, then upon reboot,
that same memory will be up for grabs and will likely be stomped on by some
application program, corrupting the system.

By the same token, it is OK to FASTROM a softloaded OS, although the
reasoning for doing so is questionable. ColdReboot() is SetFunction()ed when
a softloaded OS is made, so any foreign MMU environment will be converted
back to the protected MMU environment prior to system reset.

OVRMMU

The default operation of SoftBoot is to check to see if the MMU is in
use and print a warning message and quit if it is in use. Because
68040.library may build a MMU table, you may want to force SoftBoot to
kill a foreign MMU setup. To do so, use the OVRMMU option. The SoftBoot
options which do not result in a system reset are written as carefully
as possible to build a new MMU setup and switch over without crashing
the machine. Using the OVRMMU option, you can run multiple FASTROMs
until you fragment/run out of memory.

Note that with Softboot3.31, you can change Dev:kickstart files and
load another MMU setup over a previously existing softloaded rom. The
safer and more recommended way is to copy the kickstart file and
issue a SoftBoot KILLROM command and have your startup-sequence SoftBoot
command reload the new OS file.

ONETHREE

The most difficult mode to support: ONETHREE forces SoftBoot to load the
Devs:Kickstart1.3 file instead of the 2.0 or 3.0 SuperKickstart. Certain
things need to be known before using this parameter: 1) Reboot recovery is
via ColdCapture() for this option only. Any program which obliterates
ColdCapture() will cause the motherboard ROM OS to be reloaded on the
next hardware reset. 2) All disk partitions will be visible; this
means that 1.3 will probably try to boot from your 2.0 partition. I
didn't want to monkey with your Rigid Disk Blocks, so you need to do
one of two things: You can use HDToolBox to increase the Boot Priority
of your 1.3 partition before running 1.3, or you can make a boot floppy
which performs the assigns to your 1.3 partition and then jump to its
startup-sequence. If you choose the former, you must hold down both
mouse buttons when rebooting back to 2.0 so you can select the 2.0
partition to boot from.

The 68040 doesn't like the Bonus code real well. Kickstart 1.3 will only load
off a hard disk drive if it is the first partition on the drive and
needs to be the highest SCSI address, with six being preferable. If you
forget to change with HDTOOLBOX, a repeatable guru may be possible in 040
mode. Stick any bootable floppy into the drive to stop it. The drives
are accessable, and softboot can be directly addressed from the CLI.

However, it may just be easiest to boot from a 1.3 Workbench floppy disk.
By the way, ZorroIII is not supported in 1.3. Other than that, it works
just fine folks! Really! Remember the 68040 and 1.3 barely work together.
The 68030 and 1.3 work pretty OK: Crashes are pretty frequent. Be forewarned
and forearmed!

All partitions must have the filesystem loaded in the rigid disk block!
The stability of other than OFS and FFS partitions cannot be guranteed under
OS 1.3! Personally, I only would use 1.3 for floppies and try not to use the
hard disk at all. However, I have a lot of CDTV discs which only play under
1.3, so I will occationally use a special partition I've set up.

AmigaDos 2.0 AND ON

Actually invoking SoftBoot with no parameters or any of the remaining
ones not yet discussed will load the Devs:Kickstart file for an alternate
operating system. The following describes what these parameters are and how,
why and when to use them:

BOTH

One of the really interesting features of SoftBoot is that it works
with both the 68030 and 68040 processors. If you invoke the BOTH parameter,
MMU tables will be built to support both the 68040 and the 68030. There
really isn't much of an overhead as the 030 MMU tables require only
32K bytes of additional RAM. The 68040 can be a bit better or quite a bit
worse. The 68040 MMU tables require 9K for the basic A3000 motherboard.
That's not too bad! However, if you have a Zorro III  card, SoftBoot must
build additional MMU tables to the tune of 66K bytes per 256 megabyte
segment. This memory is all dynamically allocated as required.

The great thing about the BOTH parameter is when you have a 68040 card that
can be switched back and forth to/from the 68030: If your switch program
works, you can stay in the same RAM-based OS  without having to go
through the motherboard ROM! (OK for just a few milliseconds! Truth in
advertising, you know!).

If you don't invoke the BOTH parameter, then MMU tables will be built for
whichever CPU is currently in operation. The question naturally arises:
What if I switch CPUs? Heaven forbid, disaster surely won't come will
it? No. The RAM formerly used for the ROM and MMU tables are always allocated.
You will see a 532K (approx) loss of ram, but will be running on the
motherboard ROM. Switch back to the other CPU and the Ram-based OS will
again take effect! Neat Huh! If you want all your RAM back, use the
SoftBoot KILLROM option. You will lose everything in both modes then.

So, in conclusion, You can have one CPU running a RAM-based OS, the
other, or both running RAM-based. Or be a spoil sport and run
neither.

Note that with the Workbench V39.26 and later (Commodore's) 68040.library,
Progressive Peripherals 68040s will become unable to switch modes. You can
fix this by running a 'SoftBoot FASTROM OVRMMU'. SoftBoot's default setup will
then allow the PPS Switch program to work. Since you are rebooting to change
processors, the loss of 600K for the FASTROM will be temporary.

ENTTX

The MMU tables that 68040.library builds all assume ZorroIII I/O cards
are present. One of the things it does is turn the transparent translation
registers off. Theoretically there is a performance hit, as it only
takes one clock cycle to pass through the transparent translation registers
and three memory cycles to obtain a translation if the MMU page translation
is not stored in the 68040 address translation cache. At first glance, there
should be a major performance hit. Apparently Motorola did a wonderful
job in the ATC design as it stays there over 90 percent of the time,
minimizing the perfomance loss to about 2 percent. If you do not have
Zorro III I/O, using the ENTTX option turns on the transparent
translation registers, giving back some speed. The down side is that this
may affect how reads/writes to non-existant memory areas are handled in the
A3000. 68040.library's MMU tables will catch all accesses to non-existant
RAM without going through the jerky 350 msec hardware bus timeout. You will
lose this, in some memory areas, without using the NOBUSERRORS option,
discussed elsewhere.

NOCACHEZ2

If a Bridgeboard is detected, the ZorroII space will be automatically declared
non-cacheable. Otherwise, it is fully data and instruction cacheable
(No parameter required!). If you have any other I/O device that winds up in
the area reserved for Zorro II RAM (0x00200000-0x009fffff), then you need the
NOCACHEZ2 option. Note this also works for the 68040/1.3 mode. The 68030/1.3
MMU setup is defined in the 'Bonus' section of the Devs:Kickstart1.3 file and
is not alterable.

NOCACHEZ3

The default behavior of SoftBoot is to cache all Zorro III space. If you
have a ZorroIII I/O card, you may need to use the NOCACHEZ3 option. This
option causes both the MMU tables and the transparent translation registers
to be be declared as non-cachable. Note that this parameter has an affect
when creating a softloaded operating system and also when the ENTTX option
is invoked. In the latter case, the data transparent translation regisers
are declared serialized noncachable. If you are running the newer
68040.library, it will make the proper I/O sections non-cachable, and
leave Zorro III RAM at nearly full speed.

Z3ALL

There has been some talk about possible changes in the location of ZorroIII
autoconfiguration addresses to suit the 68040's tranparent translation
registers. When you run SoftBoot, it assumes the memory map is going to
remain the same from one OS to the next. There is no way to figure out where
the next OS might place a Zorro III board until it has gone through the
autoconfiguration process, in which case it is too late for SoftBoot to
build MMU tables. The only solution is to use the Z3ALL parameter until you
can get new ROMS/EPROMS in your A3000 which reflect the new memory
mapping. The Z3ALL parameter builds MMU tables for ALL of Zorro III space.
This is very expensive and requires over a megabyte of additional RAM.
This is the only way to make ZorroIII work if the memory map does change.
That way, there will be valid MMU tables no matter where the OS decides to
put a board. Note that the Z3ALL parameter is a NOP if there isn't a Zorro III
card in your machine.

NOBUSERRORS

When I first got my 040, I was disgusted at the number of applications
which die with an 80000004 or 80000003 Guru. Through some careful sleuthing,
I discovered that these were caused by the A3000 Bus Error control hardware.
I also discovered that the 040 was very difficult to recover from a bus error
as an RTE command just reruns the cycle. Not good unless you remap RAM
to all of the memory space (68040.library does something just like that). Even
better is that all 2.0 Kickstarts to date assume an 030 Stack frame in the
Bus Error exception handler. Apparently the 030 can fiddle with the stack and
'fake' the access. With an 040, this 'Twiddling' causes the aforementioned
Gurus. At least it winds up in a mode that brings up a requester from which
you can terminate the task or reboot. The motherboard Bus Error generation
hardware responds whenever an access is made to an address in the machine
which doesn't physically exist. This will happen on a read or a write. Yucch!
Since the ROM just ignores the cycle for the 68030, why even activate the
bus error hardware? Even worse, the hardware bus cycle takes 350 milliseconds
to generate. That is why you get those funky and jerky mouse pointers
when accesses to non-existant memory occurs.

Fortunately, there is a solution. Turn off the Bus Error generation hardware.
The NOBUSERROR parameter will perform this magic for you, enabling all
those programs which run on 68040s on the A2000 and don't on the stock-
programmed A3000 motherboard to have a chance at working. No guarantees!

Any program which accesses RAM outside of its own space is broke. Many
programs do not hurt as they only _READ_ these locations. As far as
writes goes, well there isn't RAM there anyway. But it is indicative of
a sick program. As a result, the default behavior is to let bus errors
crash a task. Use of the NOBUSERROR parameter is at your own risk.
Note that the NOBUSERROR parameter is a NOP when the 68030 or 1.3 is in
use.

NOCATCHROM

The NOCATCHROM parameter enables a custom error trapping handler to
be installed in the Bus Error exception vector. This handler only
catches and corrects writes to ROM space or areas declared invalid in
the MMU tables. A real genuine BUS error or any other type of exception
which generates a 68040 access error besides an invalid access or an illegal
write will be forwarded to the ROM Guru-handler. This is the default
operation of SoftBoot. If the NOCATCHROM parameter is involked, SoftBoot
is prevented from patching the vector. Again, this command is a NOP
under 1.3 or the 68030 processor.

TRICKS AND TIPS

1) Now that you've fallen in love with some future OS, and are very tired
at having to open a CLI/Shell and run SoftBoot manually - have I got a
trick for you! If you put SoftBoot in the Startup-Sequence, just ahead of
SetPatch, you will get a power-on SuperKickstart-like effect. The
Workbench screen does not normally open until IPrefs is run. The screen
stays white (3.0+ is black). When SoftBoot is loaded via the Startup-Sequence,
it will load your favorite version of the OS and reboot. You will see a second
dark grey/light grey/white sequence, but you will not see the
Workbench screen until you are softloaded. The second time through,
SoftBoot will detect the MMU is in operation and abort with no operation,
allowing the startup-sequence to continue! The following is the
suggested use for AmigaDos 2.0 and 3.0:

SoftBoot > nil:  [OPTIONS]
SetPatch > nil:
SoftBoot > nil: ENTTX [OPTIONS]


Note: BOTH is a recommended option if you can switch CPUs and want to always
stay in the same OS.

The second SoftBoot command (ENTTX) is to reenable the transparent translation
registers. This is optional. The only parameter for SoftBoot ENTTX is NOCACHEZ3.

Note: When installing a new Workbench via the Installer, do not let it
automatically reboot the machine when it is finished. Exit and edit the new
s:startup-sequence to reflect the SoftBoot command lines. If there is a
new kickstart file, copy it to devs:. Then reboot the machine into the
new OS via the SoftBoot KILLROM parameter.

HOW TO MAKE A 1.3 OR 2.0 OR LATER  KICKSTART

As a developer, you can obtain a new superkickstart image from CBM or
via closed listing sections on BIX. UnLharc the file and copy it to
the devs: directory to a file called Kickstart.

If you have a SuperKickstart Disk, on your 2.0 A3000 install disk is a script
file called Update2.0x. This script will create an A3000 kickstart from your
Superkickstart disk as Devs:Kickstart. For 1.3, you need the A3000 1.3
SuperKickstart Disk and use the following command from the tools directory of
the A3000 1.3 Install disk:

      Makefiles df0: 1.3 devs:Kickstart1.3

Note that you need to have the 2.0 (or later) fastfilesystem installed on all
your hard drive partitions when you use 1.3 via the ONETHREE option. Use
HDToolBox to load the proper fastfilesystem from the l: directory of your
2.04 A3000 Install disk (or wherever it may reside on future releases).

VISUAL DIFFERENCES

Whenever you reboot with the Vulcan Neck Pinch (Ctrl-LAmiga-RAmiga), you
will see a slight difference in screen behavior compared to what you are
accustomed. You will see two cycles through the black to white screen
transitions (V37 only. V39 keeps the screen black, so the second trip through
the ROM is not as obvious). The MMU is turned off on a hardware reset. The
first set of color changes is the motherboard ROM taking over. SoftBoot magic
then restores the MMU and jumps to the RAM-based ROM image, causing the second
trip through the monochrome spectrum. You will get used to it and will use it
to know when you are RAM-based versus motherboard-based.

DOWNERS

You must obey the following rules concerning RAD: 1) Never, repeat Never
ever mount RAD: and then try to SoftBoot. Softboot first, then mount RAD:
(Note the way the DOSDRIVERS drawer is accessed in Kickstart 3.0 really
helps you run SoftBoot before mounting RAD). Use the KILLROM option to remove
RAD: before SoftBooting. RAD: works from the top of memory down. SoftBoot
also wants to put the ROM at the top of memory. As you might guess, neither
wins when SoftBoot is executed! 2) Always use the BOTH option if you are going
to use both CPUs and expect RAD: to recover. RAD: seems to work much better
then because memory allocation is similar between CPU states. If you don't use
the BOTH option, RAD: will lock up the machine up when switching CPUs. It will
recover until you make the switch, however. Usually it will either hang
at the white (Black for V39) screen or continously cycle through the shades
of grey. You will have to power down to recover.

I tried hard to make this program work on the A2500/030/020. The major
problem was that the Reset command caused the loss of all chip and fastram and
the program would lock up. As a result, this version of SoftBoot is very
A3000 specific. I will be coming out with special versions to support particular
A2000/040 combinations. Also CBM does not generally make newer beta versions
of the A2000 operating system available linked at F80000, but rather at 200000.

The ONETHREE option and the Devs:Kickstart1.3 file are specific to the A3000
and a stock 1.3 kickstart image must not be used in its place.

It must be understood that you have replaced your Alpha superkickstart ROMs with
some later version, probably V2.04. Softboot requires V2.04 or later ROMS
in your machine. My A3000 is running custom-made Eproms of a much later verison.
I suspect that 3.0 ROMs will not give SoftBoot any problems.

VUNERABILITIES

Softboot can be killed in one of several ways. They all require an errant
program to write over a sensitive area of memory. First, the ROM image itself
can be corrupted if the transparent translation register is enabled.
Second, the MMU tables cannot be protected. Third, the Romtag used for
reboot recovery may get written over. And finally, the ExecBase structure
could be corrupted.

To help protect the tables (and ROM in 68040 mode), I allocate an extra 256
bytes around each item, to help prevent the OS (MemList tails) and broken
programs from overwriting critical data. The ROM is write protected at
the logical address but is vunerable if the transparent translation
registers are enabled as the physical address would not be protected;
the MMU tables are ignored in areas where the transparent translation
registers are active. SoftBoot has been made as safe as it can be.

ENFORCER

Please use the new Enforcer, V37.26 or later. It is foreign MMU tolerent.
When it exits, it will return to the previous SoftBoot MMU setup.

HISTORY

Current Version is 3.31

3.31 - All memory allocations are now checked to see that they are on
the motherboard RAM. Should any MMU table not be allocated in the proper
area, the program will print an appropriate message and exit after
returning all resources back to the old OS with no damage to the old OS.

Reordering of functions allowed the used of _LVOSumKickData() again. The
in-line code was removed.

3.30 - The MMU table fill routine was pulled out of main() and made into
two separate routines: one for 1.3 and one for 2.0+. This allows me to
change the code so I can delay the final Disable() until just before
the new OS is launched.

Caches are turned off early in the program. This required additional
flushing at several points to prevent hanging.

Supervisor() was SetFunction()ed to guarantee it would be available
after the old ROM was corrupted; SumKickData was in-lined. Now Softboot
cannot hang because the new OS has different LVOs than the last one or
depend on certain instructions & data to be in the cache.

The net result is that you can reload any OS on top of another without
worrying about corruption, or the need to make a special boot disk for
ONETHREE, for example. You can go directly from 3.0 to 1.3 now no matter
what the status of the MMU or memory allocation situation.

3.27 - It was realized that older SoftBoots can now crash because the
OVRMMU option allows one rom image to be written over the same memory area.
Previous version worked (sometimes) because LVOs didn't change or the
instruction cache contained the old rom code, while the data cache
had (from the copy of) the new ROM image. The first cut at minimizing
the problems with this was made, in particular, getting the ONETHREE
option to work with a MMUED OS. It didn't. And led to experimental
versions 3.28 & 3.29.

3.26 - Romtag assembled under SAS/C asm V6.00 (Previously used A68K PD
assembler). Compiler made to use near data and code except for assembly
functions and data. Romtags Headers made invalid if SoftBoot will not be
loading a new OS and rebooting. Executable 800 bytes smaller than 3.22.

3.25 - Same as 3.25 but C code compiled under SAS/C 6.00, previously
used SAS/C 5.10b.

3.22 - Another bug found in Zorro III when tested with Progressive ProRAM64:
Index to 3rd level MMU tables incorrectly generated. Larger of 64K*SlotSize or
BoardSize is now used to determine span of board. System Memory lists also
scanned. Should run better on A4000.

3.21 - Tested on A4000, was intermittant, but OK if run from bootup.

3.20 - New Z3ALL option added, NOCACHEZ3 option made effective in MMU tables
and ENTTX mode. Program code for SOFTBOOT parameter removed and ColdReboot()
used instead. 4K page mode removed. 68040 ROM patch search area increased from
first 20K to first 50K of ROM. ROM checksum patch search area increased to
first 10K of ROM. ColdReboot() setfunctioned to restore protected MMU
setup before system reset to prevent an unprotected ROM from getting
allocated and corrupted, hanging the machine. ColdReboot() disables
and dumps all caches (data, instruction, ATC) prior to reset.

3.14 - Version which had an option to make 4K or 8K page MMU Tables; Added
the ENTTX option; New ZorroIII MMU table generation algorithm; OVRMMU option
added. 4K mode known unstable in Softloaded OS, but stable in FASTROM.

3.0 - Changed patch to Exec to make all 68040 MMU opcode nops rather than
looking for a specific code sequence and branching around it. This will
not break again unless the patches are moved away from the beginning of the
ROM.

2.50 - Final Cleanup for Beta release to developer community for ADOS 2.0.
       It worked until exec changed in 3.0.